Spray bottles are famously finicky. How many times have you bought a cleaning product only to find that after just a few uses, the nozzle is stuck in place and therefore inoperable?
In the event of a password spraying attack, our job as defenders requires a similar level of precision: to block the entry point so that not a single drop (i.e., malicious login) gets through.
While brute force attacks are nothing new, a fresh spin on password spraying is on the rise.
Huntress has observed a whopping 155x increase in credential spraying attacks in the first half of 2026.
Much of this spike is thanks to a single campaign against Microsoft's Azure CLI originating from an IPv6 range controlled by internet hosting provider LSHIY LLC. While the campaign started months earlier, in mid-June Huntress observed more than 81 million related login attempts and 78 account compromises in just a two-week window.
Figure 1: June 22 password-spraying spike tied to the LSHIY campaign. Huntress generally saw more traffic on weekdays.
All of this and more was covered in July's Tradecraft Tuesday broadcast. Panelists Andrew "Spike" Brandt (Principal Threat Intelligence Incident Commander), Rich Mozeleski (Staff Product Manager) and Lindsey O'Donnell-Welch (Principal Technical Community Engagement Writer) walked though their recent blog breaking down the LSIHY (we decided it rhymes with "fishy") campaign and offered mitigations for prevention and remediation.
How a deprecated OAuth flow takes password spraying to the next level
A typical password spraying attack consists of the following steps:
Reconnaissance: The attacker collects valid usernames via LinkedIn, company websites, data breach dumps, and phishing to create a target list.
Build password list: The attacker assembles a short list of breached passwords, common passwords such as "Password123," company name variants, or seasonal terms.
Spray across accounts: The attacker tries one password against every account on the target list. Heeding lockout thresholds, the attacker waits before moving to the next password in a "low and slow" approach.
Gain foothold: If granted access, the attacker pivots to lateral movement, Business Email Compromise (BEC), data exfiltration, or further credential theft—often going undetected for weeks.
The attackers behind the LSHIY campaign took things a step further, thanks to a little something called Resource Owner Password Credentials (ROPC).
Deprecated in OAuth 2.1, the ROPC grant was designed to help folks migrate to using OAuth back in 2012. If provided with the correct credentials at a tenant's /token endpoint, this auth flow mints a new user-delegated token, allowing the attacker to completely bypass multi-factor authentication (MFA) and Conditional Access Policies (CAP).
As Spike put it:
"Even though we call it an authorization method, it's technically an impersonation method."
Notably, Huntress did not observe any-compromise activity after the successful logins tied to the LSHIY campaign. Rich hypothesizes that after getting their hands on a password combo list, the threat actor behind these attempts could be validating credentials to be sold on the Dark Web.
After being contacted by Huntress and others, LSHIY confirmed in early July that the attacks from this IP range had been terminated, stating that the attacker had been leveraging their bring your own IP (BYOIP) offering.
When the party is BYOIP
BYOIP is a legitimate offering that gives ISP customers peering services for the IP address ranges they own. Instead of relying on AWS/Azure addresses, threat actors can "bring" their own block and rotate to new IPs after each login attempt to evade Microsoft's Smart Lockout or other detection methods.
Attacks from the LSHIY campaign originated from IPv6 range 2a0a:d683::/32. As Rich noted, the dawn of IPv6 in 2017 dramatically increased the available IP address space, creating a sort of "wild west" of uncharted territory where both attackers and defenders can get lost.
Several Tradecraft Tuesday audience members asked questions about geolocating IP addresses used in password spraying attacks, to which Spike quipped: "Geolocation on IPv6 is kind of a hot mess right now."
Since LSHIY's takedown, the threat actor appears to have moved to an IP block hosted by ISP FranTech (AS53667), spraying from two IPv6 ranges (2605:6400::/32, 2605:6404::/32), as well as IPv4 ranges via Tor exit nodes. Notably, the volume of attempts has decreased significantly.
Several other members of the infosec and MSP community commented during the event that they had seen similar traffic originating from German ISP 3xK Tech. These interchangeable peering services create a familiar "whack-a-mole" threat hunting scenario for defenders.
MFA it, don't spray it
The LSHIY campaign does not appear to be targeting any specific industry, but opportunistically taking advantage of organizations with poor password hygiene and/or improperly configured MFA. Of 23 impacted businesses Huntress analyzed, all but eight had MFA implemented. One third of the remaining 15 had their MFA scoped to specific users, meaning that certain groups (like owners tied to ROPC) were excluded.
Figure 2: Breakdown of how organizations impacted by the LSHIY campaign had MFA configured (or not)
This doesn't mean that MFA is broken; it means that Conditional Access Policies need to be scoped to be properly enforced. Dozens of commenters in the Tradecraft Tuesday chat bemoaned the challenges of fine-tuning conditional access policies without regularly locking out legitimate users.
Lindsey drove the point home:
"Conditional Access Policies are confusing. As you can see, we even had businesses with MFA configured with an explicit policy that called to block this very specific vector get hit."
Read our recent blog on another OAuth attack to learn about more flavors of CAP misconfigurations.
Don't get hosed
We're not the only ones seeing this: More than three quarters of Tradecraft Tuesday audience members polled had noticed an uptick in password spraying attempts in their environments, with several people calling out Azure CLI specifically.
Huntress recommends the following mitigation strategies to protect your users from password spraying attacks:
Enforce password hygiene, consider passwordless options.
Disable ROPC (or apps that rely on it) from your system.
Restrict the Azure CLI application for non-admin users.
Don't trigger response based on spray volume (pointing at the most-sprayed, least-compromised tenants) — prioritize by credential validity instead.
Require MFA (or block) for All Users, All Cloud Apps, and All Client App types unconditionally.
Using a strong Conditional Access setting like
userStrongAuthClientAuthNRequiredto enforce strong authentication at the client.
Rick put it well:
"Appropriately configured and managed conditional access is a superpower."
Like what you just read? Join us every month for Tradecraft Tuesday, our live webinar where we expose hacker techniques and talk nerdy with live demos. Snag your spot now!
